Connecting to a cloud service for secure access

ABSTRACT

A client may connect to a server over an insecure network by downloading and configuring a secure connection mechanism to the server. The secure connection mechanism may allow the client to join a domain when connected to the server and access domain level services. The server may receive a request from the client, classify the connection type, and used the classification to determine whether the request originated off premises. If so, the server may send a configuration mechanism to the client, which may then establish a secure connection to the server. Once the secure connection is established, the server may join the client to the server&#39;s domain and begin secure operations.

BACKGROUND

Some connections between clients and servers use elevated security andauthentication mechanisms to deliver various services. The services mayinclude domain level connections through which access to secure filesystems, computer maintenance operations, or other services that maymanage access to secure data and client computer configuration.

SUMMARY

A client may connect to a server over an insecure network by downloadingand configuring a secure connection mechanism to the server. The secureconnection mechanism may allow the client to join a domain whenconnected to the server and access domain level services. The server mayreceive a request from the client, classify the connection type, and usethe classification to determine whether the request originated offpremises. If so, the server may send a configuration mechanism to theclient, which may then establish a secure connection to the server. Oncethe secure connection is established, the server may join the client tothe server's domain and begin secure operations.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings,

FIG. 1 is a diagram illustration of an embodiment showing a system forconfiguring a remote device for access to a domain.

FIG. 2 is a flowchart illustration of an embodiment showing a method foradding a new client.

FIG. 3 is a flowchart illustration of an embodiment showing a method forcreating an installation package.

DETAILED DESCRIPTION

A remote client may be authenticated and operate within a server'sdomain by a secure connection mechanism. The client may request accessto the server, and the server may identify and classify the request.Based on the classification, the server may prepare a connectioninstallation file that may be downloaded and installed on the client.The connection installation file may configure the client for one ofseveral types of secure connections. When the client establishes asecure connection, the server may further configure the client foraccess to elevated services.

The client and server system may be deployed as a cloud based servicethat manages client devices. The server may provide various managementservices that may configure and manage the client device. Because themanagement services may have access to configuration aspects of theclient device, and because the client device may have access tosensitive data that may be available from the server, all connectionsbetween the devices may be performed using secure connectiontechnologies.

The initial connection request from a remote client to a server may bean unsecure request. In a typical embodiment, the initial connectionrequest may be a request made through a web browser, for example. Theserver may examine the request to determine whether or not the requestcame from inside or outside a domain network. When the request comesfrom outside the domain network, the server may create a setupinstallation file and transmit the installation file to the client.

The client may install the setup installation file. The installationfile may configure the client for one of several types of secureconnections, based on the operating system and other configurationparameters of the client. After installation, a secure connection may bemade to the server. Once the secure connection is made, a user maypresent credentials and be authenticated to join a domain. After theclient is joined to the domain, the client and server may begin securecommunications on a domain level.

The installation file may be created on-the-fly and may be customizedfor the potential connection mechanisms that a client device may use. Incases where user input may be used to select various options, theinstallation file may include a wizard or other user interfacecomponent. When the installation system can automatically determine aconnection mechanism, the installation file may be configured to executewithout a user interface.

In some embodiments, the installation file may be customized based on anentry in a domain database. The entry may be configured beforehand andmay contain the device type and other configuration parameters. When adevice type may be determined, a subset of the available connectionmechanisms may be identified for inclusion in the installation file.When no such device type is available, all of the potential connectionmechanisms may be included in the installation file.

When installation file is created, the various connection mechanisms maybe customized or configured for the specific connection. Someembodiments may use different connection parameters for each device.Some such embodiments may not permit two devices to use the sameconnection. For example, each device may be assigned a specific port fora connection where no two devices share the same port. Such embodimentsmay permit fine grained control over how each device connects to a localnetwork.

Throughout this specification, like reference numbers signify the sameelements throughout the description of the figures.

When elements are referred to as being “connected” or “coupled,” theelements can be directly connected or coupled together or one or moreintervening elements may also be present. In contrast, when elements arereferred to as being “directly connected” or “directly coupled,” thereare no intervening elements present.

The subject matter may be embodied as devices, systems, methods, and/orcomputer program products. Accordingly, some or all of the subjectmatter may be embodied in hardware and/or in software (includingfirmware, resident software, micro-code, state machines, gate arrays,etc.) Furthermore, the subject matter may take the form of a computerprogram product on a computer-usable or computer-readable storage mediumhaving computer-usable or computer-readable program code embodied in themedium for use by or in connection with an instruction execution system.In the context of this document, a computer-usable or computer-readablemedium may be any medium that can contain, store, communicate,propagate, or transport the program for use by or in connection with theinstruction execution system, apparatus, or device.

The computer-usable or computer-readable medium may be for example, butnot limited to, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, device, or propagationmedium. By way of example, and not limitation, computer-readable mediamay comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer-readable instructions, data structures,program modules, or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium which can be used tostore the desired information and may be accessed by an instructionexecution system. Note that the computer-usable or computer-readablemedium can be paper or other suitable medium upon which the program isprinted, as the program can be electronically captured via, forinstance, optical scanning of the paper or other suitable medium, thencompiled, interpreted, of otherwise processed in a suitable manner, ifnecessary, and then stored in a computer memory.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism and includesany information delivery media. The term “modulated data signal” can bedefined as a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in the signal. By wayof example, and not limitation, communication media includes wired mediasuch as a wired network or direct-wired connection, and wireless mediasuch as acoustic, RF, infrared and other wireless media. Combinations ofany of the above-mentioned should also be included within the scope ofcomputer-readable media.

When the subject matter is embodied in the general context ofcomputer-executable instructions, the embodiment may comprise programmodules, executed by one or more systems, computers, or other devices.Generally, program modules include routines, programs, objects,components, data structures, and the like, that perform particular tasksor implement particular abstract data types. Typically, thefunctionality of the program modules may be combined or distributed asdesired in various embodiments.

FIG. 1 is a diagram of an embodiment 100, showing a network environmentin which a client device may establish a secure connection with aserver. The server may create an installation package and transmit thatpackage to a client device prior to authenticating the client device.

The diagram of FIG. 1 illustrates functional components of a system. Insome cases, the component may be a hardware component, a softwarecomponent, or a combination of hardware and software. Some of thecomponents may be application level software, while other components maybe operating system level components. In some cases, the connection ofone component to another may be a close connection where two or morecomponents are operating on a single hardware platform. In other cases,the connections may be made over network connections spanning longdistances. Each embodiment may use different hardware, software, andinterconnection architectures to achieve the described functions.

Embodiment 100 illustrates a network environment in which a system 102may process connection requests from client devices 146. The initialcontact between a client device 146 and the system 102 may be made in anunauthenticated manner. Such a request may be made, for example, througha web page where the client device may request a connection.

While the connection between the devices is unauthenticated, the system102 may create an installation package for the client device. Theinstallation package may include configuration parameters, scripts,executables, or other types of information that may be downloaded andinstalled on the client device. The client device may then be configuredusing one or more secure communication mechanisms by which a securecommunication channel may be created between the devices.

The device 102 is illustrated having hardware components 104 andsoftware components 106. The device 102 as illustrated represents aconventional computing device, although other embodiments may havedifferent configurations, architectures, or components.

In many embodiments, the device 102 may be a server computer. In someembodiments, the device 102 may still also be a desktop computer, laptopcomputer, netbook computer, tablet or slate computer, wireless handset,cellular telephone, game console or any other type of computing device.

The hardware components 104 may include a processor 108, random accessmemory 110, and nonvolatile storage 112. The hardware components 104 mayalso include a user interface 114 and network interface 116. Theprocessor 108 may he made up of several processors or processor cores insome embodiments. The random access memory 110 may be memory that may bereadily accessible to and addressable by the processor 108. Thenonvolatile storage 112 may be storage that persists after the device102 is shut down. The nonvolatile storage 112 may be any type of storagedevice, including hard disk, solid state memory devices, magnetic tape,optical storage, or other type of storage. The nonvolatile storage 112may be read only or read/write capable.

The user interface 114 may be any type of hardware capable of displayingoutput and receiving input from a user. In many cases, the outputdisplay may be a graphical display monitor, although output devices mayinclude lights and other visual output, audio output, kinetic actuatoroutput, as well as other output devices. Conventional input devices mayinclude keyboards and pointing devices such as a mouse, stylus,trackball, or other pointing device. Other input devices may includevarious sensors, including biometric input devices, audio and videoinput devices, and other sensors.

The network interface 116 may be any type of connection to anothercomputer. In many embodiments, the network interface 116 may be a wiredEthernet connection. Other embodiments may include wired or wirelessconnections over various communication protocols.

The software components 106 may include an operating system 118 on whichvarious applications and services may operate. An operating system mayprovide an abstraction layer between executing routines and the hardwarecomponents 104, and may include various routines and functions thatcommunicate directly with various hardware components.

The software components 106 may include a web service 120 through whicha client device 146 may communicate with the system 102. The web service120 may respond to HTTP or other requests so that a user on a clientdevice 146 may access the system 102 through a web browser or otherapplication.

When a user communicates with the web service 120, the user may be givenan option to download an installation package for a secure connection.The secure connection may allow the user to access services within asecure network. Some embodiments may have some services or data that maybe accessible by the user without such a secure connection.

An initial request for communication from a client device 146 may beanalyzed by an incoming request analyzer 122. The incoming requestanalyzer 122 may process the incoming request to obtain as muchinformation as possible. In some embodiments, the incoming requestanalyzer 122 may analyze merely an HTTP request, while other embodimentsmay have some back-and-forth communication to obtain additionalinformation.

From the initial request, the incoming request analyzer 122 may separatethose devices within a local or domain network and those devices outsidethe network. Requests that come from within a local domain may proceedto authentication without an installation package. Requests that comefrom outside the local domain may have an installation package createdand downloaded to the client prior to authenticating.

The incoming request analyzer 122 may query a domain database 124 todetermine if the requested device has an entry in the domain database.When the device may be attempting to connect remotely and the devicedoes not have an entry in the domain database, some embodiments mayrefuse a connection request. Such embodiments may permit remoteconnections when the domain database entry is created before the requestand may otherwise reject requests. Such embodiments may provide anadditional layer of security, as each remote secure connection may haveto be manually configured prior to connecting.

For many client devices, the configuration of secure connectionmechanisms may be tedious or confusing for a lay person. Some secureconnections may have specific addresses or configuration parameters thatare used to establish secure connections, and these addresses andparameters may be difficult or confusing for a user to enter andconfigure.

A downloader 126 may create an installation or setup file that may bedownloaded and executed by a remote client. The setup file may includeaddresses, configuration information for various connections, securitycertificates, and scripts or other executable code.

The setup file may include addresses or other connection information fora secure connection. In some embodiments, the addresses included in thesetup file may be Internet Protocol (IP) addresses in either or bothIPv4 or IPv6 protocols. Some embodiments may establish various ports orother connection parameters as well.

In some embodiments, a secure connection may be accepted through asingle address for multiple remote devices. Such embodiments may directall secure connections to a single port or address on a singleauthenticating system.

Other embodiments may include multiple connection addresses. In suchembodiments, a secure connection may be attempted through many differentservers, each having a separate address. Such embodiments may be usedwhere load balancing or redundancy may be desired. When one server isunavailable either by being overloaded or being offline, the client maydirect a request to another server.

Multiple connection mechanisms may be available for remote devices toconnect securely. For example, some devices may support Virtual PrivateNetwork (VPN) connections, secure tunneling through IPSec, or otherconnection mechanisms that may be available through traditional Internetconnections. Other devices may support various secure connectionsavailable through cellular telephone networks or other communicationsnetworks.

The setup file may include executable code, which may be binaryexecutable code, scripts, or other instructions that may be executed bythe client device. The executable code may configure the remote devicefor a secure connection. In some embodiments, the executable code may becapable of executing without user interaction. Other embodiments mayhave some user interaction.

The downloader 126 may create a setup file for a client device that istailored to the client device's capabilities. The downloader 126 mayretrieve connection setup routines 128 that correspond with thecapabilities of the remote device. Various configuration parameters 130for the secure connections may also be included.

Various security components may be included in a setup file. Thecomponents may include a security certificate 132, from which a publicencryption code may be derived. The public encryption code may be usedto encrypt transmissions sent to the server, as well as to decryptcommunications from the server.

An incoming authentication processor 134 may receive and process thesecure connection requests. The incoming authentication processor 134may authenticate a connection requests against the domain database 124to determine whether or not a secure connection may be established. Onceauthentication is successful, a remote device may be joined to a localdomain and given access to various services within the network.

The system 102 may be connected to two networks: a domain network 136and an external network 144.

The domain network 136 may include various servers 138 that may have ahardware platform 140 providing various services 142. In a typicaldeployment, the services 142 may include file services, access toapplications, or other services. In a commercial or enterpriseenvironment, the services may contain sensitive data.

In some embodiments, the domain network 136 may also include anauthenticating system 156. The authenticating system 156 may have ahardware platform 158 on which an incoming authentication processor 160may execute. In some embodiments, one system 102 may process non-securerequests while a second authenticating system 156 may provideauthenticated, secure connections to the domain network 136.

The external network 144 may be an insecure network, such as theInternet. Various remote client devices 146 may attempt to establishsecure connections with the domain network 136.

The remote client devices 146 may have various hardware platforms 148 onwhich an operating system 150 may operate. The operating system 150 mayhave different connection mechanisms 152 that may be accessed by variousapplications 154. The applications 154 may include web browsers andother applications.

The remote client devices 146 may be any type of computing device, suchas personal computers, servers, game consoles, cellular telephones,tablet computers, or any other computing device.

FIG. 2 is a timeline illustration of an embodiment 200 showing a methodfor adding remote clients to a system. The process of embodiment 200illustrates the operations of a client device 202 on the left column,the operations of a front end server 204 in the center column, and theoperations of an authenticating server 206 in the right hand column.

Other embodiments may use different sequencing, additional or fewersteps, and different nomenclature or terminology to accomplish similarfunctions. In some embodiments, various operations or set of operationsmay be performed in parallel with other operations, either in asynchronous or asynchronous manner. The steps selected here were chosento illustrate some principles of operations in a simplified form.

Embodiment 200 illustrates a simplified exchange between a client device202 and various servers prior to establishing a secure connection. Thefront end server 204 may create an installation routine that may beinstalled or executed on the client device 202. Once installed, theclient device 202 may be able to establish secure connections with anauthenticating server 206.

The client device 202 may establish an initial connection in block 208with the front end server 204. The front end server 204 may receive theconnection request in block 210 and analyze the address or othercomponents of the request in block 212.

The analysis of the request in block 212 may attempt to identify theorigin of the client device 202. In some embodiments, the front endserver 204 may request further information in block 214, which may bereceived in block 216 and information returned in block 218 by theclient device 202. The additional information may be received in block220.

If the front end server 204 determines that the client device is insidethe local network in block 222, the request may be forwarded in block224 to the authenticating server 206. The authenticating server 206 mayreceive the request in block 226, may join the device to the domain inblock 228, and may permit access to the network in block 230.

If the requestor is not in the local network in block 222, a setup filemay be created in block 232. An example of a process for creating asetup file may be found in embodiment 300 later in this specification.

The setup file may be transferred in block 234 by the front end server204 and downloaded in block 236 by the client device 202. The clientdevice 202 may install the setup file in block 238, then transmit asecure connection request in block 240 to the authenticating server 206.

The authenticating server 206 may receive the request in block 242 andmay establish a secure connection in blocks 244 and 246. As part of thesecure connection, a user or device may present credentials that may beused to authenticate the user and device to the domain network. Onceauthenticated, the client device may be joined the domain network inblock 248 and access to the domain may be permitted in block 250.

FIG. 3 is a flowchart illustration of an embodiment 300 showing a methodfor creating an installation package. The process of embodiment 300 maybe performed by a downloader, such as the downloader 126 of embodiment100.

Other embodiments may use different sequencing, additional or fewersteps, and different nomenclature or terminology to accomplish similarfunctions. In some embodiments, various operations or set of operationsmay be performed in parallel with other operations, either in asynchronous or asynchronous manner. The steps selected here were chosento illustrate some principles of operations in a simplified form.

Embodiment 300 illustrates a method for creating a customizedinstallation file in response to a secure request. The installation filemay be customized to include specific parameters for any connection orauthentication mechanism, and may also include installation executablesthat may be used by a client device to configure a secure connection. Insome embodiments, a single setup file may contain configurationinformation for several different types of secure communicationmechanisms.

In block 302, a request may be received. The request may be analyzed inblock 304 for any indicators. An indicator may be any identifier,address, or other information that may be used to determine the originor transmission route of the request. From the analysis, the requestormay be classified as being inside or outside of the local network. Ifthe requestor is inside the local network in block 306, the request maybe forwarded to a local authentication server in block 308.

If the requestor is determined to be outside the local network in block306, the device may be looked up in a domain database in block 308. Ifan entry is not found in the domain database in block 312, the requestmay be denied in block 314.

If the requestor does have an entry in block 312, some embodiments mayhave hints or additional information about the requestor in block 316.The hints may include metadata about the device, such as device type,operating system, available connections, or other information.

When no additional hints may be available in block 316, all potentialconnection mechanisms may be selected in block 318. When some hints areavailable in block 316, the device type may be determined in block 320and the possible connections may be identified in block 322.

An installation package may begin construction in block 324.

For each potential connection mechanism in block 326, the connectionparameters for that connection mechanism may be determined in block 328and the setup executable for the connection mechanism may be added tothe connection package in block 330.

Given the parameters of the device and possible connections, an analysismay be made in block 332 to determine whether or not the client devicemay be able to automatically detect which connection mechanism may beappropriate. If the client cannot auto-detect in block 332, a wizard orother user interface component may be added to the package in block 334.If the client can auto-detect in block 332, fully automated installationcode may be added to the package in block 336.

The installation package may be finalized in block 338 and may betransmitted to the client device in block 340.

The foregoing description of the subject matter has been presented forpurposes of illustration and description. It is not intended to beexhaustive or to limit the subject matter to the precise form disclosed,and other modifications and variations may be possible in light of theabove teachings. The embodiment was chosen and described in order tobest explain the principles of the invention and its practicalapplication to thereby enable others skilled in the art to best utilizethe invention in various embodiments and various modifications as aresuited to the particular use contemplated. It is intended that theappended claims be construed to include other alternative embodimentsexcept insofar as limited by the prior art.

What is claimed is:
 1. A server comprising: a processor; a requestanalyzer, executed by said processor, that: receives a request for aconnection from a client device; determines that said request is anunsecure request; determines an address for said request; and determineswhether said address is within or outside a domain; a downloader,executed by said processor, that: in response to said address beingoutside said domain, and while connection with said client device isunsecure, creates a setup file comprising: an address for said server; asetup configuration for a secure connection mechanism; and a securitycertificate for said server; and transmits said setup file to saidclient device for installation by said client device; and anauthentication processor that: receives a secure connection request fromsaid client device; establishes a secure connection with said clientdevice using said secure connection mechanism; and joins said clientdevice to said domain, wherein in response to said address being withinsaid domain, said authentication processor authenticates said requestwithout said setup file being transmitted by said downloader to saidclient device for installation by said client device.
 2. The server ofclaim 1, wherein said request analyzer determines that an account forsaid client device exists if an entry for said client device exists in adatabase associated with said domain.
 3. The server of claim 1, whereinsaid request analyzer: determines that an account for said client devicedoes not exist if an entry for said client device does not exist in adatabase associated with said domain; and stops processing said request.4. The server of claim 1, wherein said setup file further comprises anadditional setup configuration for an additional secure connectionmechanism.
 5. The server of claim 1, wherein said setup file furthercomprises an installation routine executable on said client device. 6.The server of claim 1, wherein said setup file: analyzes at least oneparameter on said client device; and uses said at least one parameter toselect between said secure connection and an additional secureconnection.
 7. The server of claim 1, wherein said setup file comprisesa user interface wizard.
 8. The server of claim 1, wherein said setupfile configures said client device to connect using said secureconnection mechanism for future requests.
 9. The server of claim 1,wherein said secure connection mechanism comprises a virtual privatenetwork connection.
 10. The server of claim 1, wherein said secureconnection mechanism comprises an IPSec tunnel between said clientdevice and said server.
 11. A method comprising: receiving a request fora connection from a client device; determining that said request is anunsecure request; determining an address for said request; determiningwhether said address is within or outside a local domain; determiningthat said client device has an existing account on said local domain andthat said client device is to be joined to said local domain; inresponse to said address being outside said local domain, whileconnection with said client device is unsecure, creating a setup filecomprising: an address for a secure connection; a setup configurationfor a secure connection mechanism; and a public key for a securitycertificate for said local domain; and transmitting said setup file tosaid client device for installation by said client device; receiving asecure connection request from said client device; establishing a secureconnection with said client device using said secure connectionmechanism; and joining said client device to said local domain; and inresponse to said address being within said local domain, authenticatingsaid request without transmitting said setup file to said client devicefor installation by said client device.
 12. The method of claim 11further comprising decrypting at least a portion of said request using aprivate key for said security certificate.
 13. The method of claim 11,wherein said setup file further comprises an executable code thatconfigures said client device to establish a connection using saidsecure connection mechanism for subsequent requests.
 14. The method ofclaim 11, wherein said setup file further comprises an additional setupconfiguration for an additional secure connection mechanism.
 15. Themethod of claim 11, wherein said setup file analyzes said client deviceto select between said secure connection mechanism and an additionalsecure connection mechanism.
 16. The method of claim 11, wherein saidrequest is received by a first server and said secure connection requestis received by a second server.
 17. A server comprising: a processor; arequest analyzer, executed by said processor, that: receives a requestfor a connection from a client device; determines that said request isan unauthenticated request; determines an address for said request;determines whether said address is within or outside a domain;determines a host name for said client device; determines that said hostname has an account on said domain and that said client device is to bejoined to said domain; and launches a downloader based on said accountin response to said address being outside said domain; wherein saiddownloader: while connection with said client device is unauthenticated,creates a setup file comprising: an address for said server; a setupconfiguration for a secure connection mechanism; a security certificatefor said server; and an executable code to configure said client deviceto perform a secure connection; and transmits said setup file to saidclient device for installation by said client device; and anauthentication processor that: receives a secure connection request fromsaid client device; determines that said secure connection requestcomplies with said secure connection mechanism; establishes a secureconnection with said client device using said secure connectionmechanism; and joins said client device to said domain, wherein inresponse to said address being within said domain, said authenticationprocessor authenticates said request without said setup file beingtransmitted by said downloader to said client device for installation bysaid client device.
 18. The server of claim 17, wherein said secureconnection mechanism comprises an IPSec tunnel.
 19. The server of claim17, wherein said authentication processor is separate from said requestanalyzer.
 20. The server of claim 17, wherein said request analyzer is awebsite configured to receive said request for a connection.